By David Long, Vitech President
There is no doubt that systems engineering is growing. It is growing in applicability as the degree of complication and complexity rises across many different application domains – aerospace and defense, transportation, automotive, energy, medical, consumer products, and more. It is growing in importance as we seek to deliver value efficiently and effectively, free from unintended consequences. But as systems engineering grows, there is a groundswell of frustration as well – that what people call systems engineering is not really systems engineering at all.
This complaint has increasingly been raised in private discussions, small meetings, and public forums, and I share that sense of frustration. It is often framed in terms of individual practitioners and organizations performing “partial systems engineering” or “checklist systems engineering,” sometimes tinged with a sense of nostalgia for the early days of the practice. Rarely do I hear it framed in an “us versus them” mindset, but more often in a constructive question of how do we make good systems engineering more accessible to all those who could benefit from good application and good practice.
First off-ramp: apprehending only a subset of systems engineering
The solution starts by recognizing that there are multiple off-ramps on the way to good systems engineering. The first off-ramp is seeing, intellectually grasping, and implementing only a subset of systems engineering – most often requirements management. There is absolutely nothing wrong with requirements management. It is an essential part of good problem solving and good systems engineering. However, it is a very limited subset and is by no means a substitute for systems engineering.
How do we fall into this trap – creating and then taking this off-ramp? Quite often it comes from returning to our reductionist roots which have served us so well since the Scientific Revolution. We break problems – and disciplines – down into smaller and smaller pieces in order to increase understanding. We then hope to assemble the pieces into a working whole.
This approach has served us well for centuries but breaks down when addressing the interconnected, interdependent, highly complicated, and often complex problems, solutions, and environments of today. Hence the birth of systems engineering, but ironically even this practice based on holism is subjected to reductionism as people seek to break systems engineering down into its constituent parts, practice each independently, and then assemble the right outcome. The moment we break systems engineering into parts, we both violate its fundamental principles and run the risk of individuals substituting a part for the whole – knowingly or, more often, unknowingly. This is exactly the case with requirements management as a decoy for systems engineering.
Second off-ramp: substituting process for thinking
The second off-ramp is substituting process for thinking and creating so-called “checklist systems engineering.” Again, process is a critical component of performing anything complex in an appropriate and repeatable manner. However, process – neither purpose nor totality – is only a partial enabler. Here we need to be very aware and very careful of the way we position our practice, because we are part of the problem. INCOSE’s most-cited definition of systems engineering is “an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder’s needs are satisfied in a high-quality, trustworthy, cost-efficient and schedule-compliant manner throughout a system’s entire life cycle” – a process-centric mentality. Likewise, the most cited systems engineering is ISO/IEC/IEEE 15288:2015 – systems and software engineering – system life cycle processes. We must stop enabling – if not encouraging – this misinformed substitution of process for practice.
For those lacking a deeper understanding, process easily becomes a proxy. The thinking is that if I follow the process, I am doing the practice and will deliver the results. If the process is tailored to the circumstance and performed properly in the context of principles, supporting methods, and experience, that conclusion is absolutely true. However, we all know that process executed in isolation is useless at best, harmful at worst – and I suspect we have all observed practitioners doing just this under the title of systems engineering.
Third off-ramp: a misunderstanding of MBSE
The most recent off-ramp to emerge between many practitioners and good systems engineering is the rise of model-based systems engineering – or more specifically the misunderstanding of MBSE. Like requirements management and process, MBSE done right is an enabler of the modern practice of systems engineering designed to address the reality of today’s problems and solutions. However, MBSE is easily misunderstood – as a distinct approach, as a constrained practice to be performed in specific ways with specific notations, or most often simply as a series of diagrams. Much as in the first two off-ramps, sometimes the misunderstanding is simply naiveté on the part of the practitioner. In other cases, again we share the blame in the way we have framed (or misframed) this tool in our systems engineering toolkit.
These off-ramps emerge – and are taken – for a variety of reasons. The first is by far the most innocent but also the most damaging – simple misunderstanding. Misunderstanding on the part of the practitioner who believes he is doing the right thing but simply lacks greater knowledge. Misunderstanding on the part of the individual, group, or organization who builds the off-ramp thinking that they are enabling good practice when in reality they are creating a false substitute.
The second is more frustrating to those committed to advancing the state of the practice – personal or commercial gain. Approximately 15 years ago the developer of a then-popular requirements management tool told the story of starting with systems engineering and then “dumbing the tool down” (his language, not mine) until procurement could understand what was being sold. Today, I know many spearheading the charge of MBSE within organizations who are knowingly incorrectly positioning the implementation and approach in furtherance of their interests at the ultimate expense of the organization.
The third case is errantly substituting what is expedient or efficient for what is effective. Sometimes this is cloaked in the language of simplification (after all, systems engineering can be quite complex). Sometimes it begins with the thought, “If I can only get them started, then I can correct the path later.” Too often, later never comes.
There are many other off-ramps on the way to good systems practice. We could attempt to enumerate them all, but the moment we do so, other off-ramps would emerge. The answer is not to identify every possible error in the hopes of avoiding them. The answer is to return to first principles which will keep us on track throughout the journey. The answer is also to reduce the barriers to entry for good systems engineering, simplifying without becoming simplistic in order to help practitioners stay on course.
There is art in engineering
Whereas the oft-cited INCOSE definition focuses on interdisciplinary process, I prefer descriptions that highlight an interdisciplinary or transdisciplinary approach and practice that can be appropriately tailored to different levels of complication and complexity. Jon Wade of Stevens Institute emphasizes two critical aspects – the lifecycle perspective and the creative act of design, noting that, “There is art in engineering, not just science and analysis.” Richard Beasley of Rolls Royce says, “Systems engineering collects and organizes all the information to understand the whole problem, explores it from all angles, and then finds the most appropriate solution.” Stanley McChrystal in Team of Teams describes systems engineering and addresses examples from across many different application domains without resorting to “tech speak.” We can learn from all of these individuals as we work not to reduce or simplify systems engineering, but instead to make the critical concepts more accessible to those with different levels of experience and varied backgrounds.
Resolutions are generally made in the New Year, but let us begin (early) with the end in mind. Let us resolve to reach out and welcome individuals and organizations to this systems engineering practice, recognizing that today more than ever before the world needs good systems engineering. Let us resolve to make systems engineering more intellectually accessible, not by creating decoys and becoming simplistic, but by emphasizing first principles and good communication. Let us resolve to combat off-ramps at every opportunity – refusing to take them ourselves, teaching and coaching those that we see moving off-track, and rejecting the creation of new off-ramps whatever the purpose.
If we are willing to make and follow through on these resolutions, we can move systems engineering from an oft misunderstood and misapplied process to an important and impactful practice, changing the world for the better. And isn’t that exactly what resolutions – and systems engineering – are for?
